The present invention relates to the field of communication systems, and more particularly to a system and method for providing traffic engineering services by communicating application objects over a soft state network protocol.
Telecommunication networks often implement processes, such as Resource Reservation Protocol (RSVP), which implement soft states while operating. Soft states are memory blocks allocated by processes executing at one or more nodes along the process transmission path, used to track various characteristics of the process and/or the network operation.
The RSVP process has conventionally been used to provide traffic engineering functions, such as ensuring that a particular network application can receive a particular service, such as a given amount of bandwidth without experiencing a specified level of delay. In RSVP operation, a sending application sends a request known as a path signal to a desired destination application. Network elements between the source and destination applications receive the path signal, and create a soft state, typically including the address of the network element that passed the path signal to the current network element.
When the path signal reaches the destination network element, if sufficient network resources are available to satisfy the reservation request, a reservation signal is created and communicated back to the sending application through the same transmission path. Each node receiving the reservation signal creates determines whether sufficient network resources continue to exist and, if so, creates another soft state corresponding to the reservation signal and forwards the reservation signal to the next hop. When the sending network element receives a reservation signal, the reservation request has been confirmed.
To maintain the reservation, RSVP requires that the soft states at each intermediate node periodically be refreshed with additional path and reservation messages. If the soft states are not refreshed, the path breaks down, or is torn down with an explicit path tear message, and the sender must reestablish a new reservation.
Network processes that implement soft states can create problems when networks attempt to implement efficiency algorithms, such as signal aggregation, packet protection, and/or crankback. Signal aggregation typically involves determining that two or more signal flows share a common characteristic, such as passage through common network elements, and transmitting those two signals over all or a part of the network using a common signal trunk (e.g., a collection of signal flows sharing a common signal path). Using conventional aggregation techniques, each network element along the aggregation path is typically aware of the aggregation algorithm and is capable of adding and deleting signal flows from the aggregation trunk. Each node, therefore, commonly tracks information about each signal flow being communicated, requiring storage of vast amounts of information at each node. This problem can be exacerbated when using a process, such as RSVP, that implements soft states. In those cases, each signal flow will require even more information to be stored at each intermediate node, and constant refreshment of that information during operation. Processes using soft states in combination with network efficiency algorithms, such as aggregation, therefore, place heavy loads on the network elements, both in terms of data storage and processing.
In addition, in the particular example of RSVP, typical RSVP processes do not facilitate packet protection, and also do not allow for crankback (finding an alternate path if the reservation, for some reason fails).
The present invention recognizes a need to facilitate network efficiency algorithms, such as flow aggregation, packet protection, and reservation crankback, for processes using soft states, without placing heavy data storage and processing burdens on each of the network elements. Accordingly, the present invention seeks to reduce or eliminate some of the aforementioned problems identified with other approaches.
In accordance with the present invention, a method of facilitating traffic engineering services by communicating application objects over soft state process messages comprises receiving an external soft state process initiating message at an ingress node to a core cloud, the core cloud comprising a plurality of nodes associated with a central processor, and generating an internal soft state process initiating message including an appended first application object. The method further comprises communicating the internal soft state process initiating message to an egress node of the core cloud, receiving at the ingress node an internal soft state process confirming message including an appended second application object, and providing a traffic engineering service based, at least in part, on the first or second application data.
In a particular embodiment of the invention, with little or no alteration of conventional soft state protocol, the invention facilitates complex traffic engineering functionality that would not otherwise be available using conventional soft state protocols, or that would require significant alterations to the standard soft state protocols and/or additional processing and storage requirements.
Various embodiments of the present invention may exhibit some, none, or all of the following technical advantages. For example, the invention facilitates providing various traffic engineering services while conserving significant system resources. In a particular embodiment, using the information transmitted for the soft state process as a carrier, the invention can communicate application objects between an ingress core node and an egress core node to provide additional functionality, without the need to program intermediate core nodes with the application or to involve those nodes in processing any application data. By piggy backing application protocols over soft state processes executing on some, but not all of the core nodes, and communicating application data transparently over the process data, the particular embodiments of the invention can facilitate significant additional processing of signals used in soft state processes, without requiring substantial additional processing or storage requirements at each node on the signal""s path.
As a particular example, conventional RSVP protocol offers no procedure for seeking an alternate traffic flow upon failure of a reservation request. In a particular embodiment of the present invention, failed reservation request on traffic flows within the core cloud can be replaced with alternate traffic flows/traffic trunks. Using information contained in the application objects piggybacked onto standard RSVP state messaging, this aspect of the present invention facilitates features, such as, reservation crankback and packet protection, which are not available in conventional RSVP processes. At the same time, by programming the applications into the ingress and egress nodes of the core cloud, but not all intermediate core nodes, the present invention conserves system resources.
In another embodiment of the present invention, traffic flows can be aggregated onto common traffic trunks within the core cloud, reducing the number of refresh messages passed over the core cloud. The ingress node and egress node can be programmed with algorithms to aggregate traffic flows and deaggregated traffic flows, respectively. When the core cloud receives a refresh path message, or a refresh reservation message associated with a traffic flow on an aggregated path, the invention need only transmit the refresh messages once for all traffic flows on the same aggregated trunk. In this manner, the invention avoids having to store separate state information for each traffic flow at each node, and avoids having to send separate refresh messages for each traffic flow, saving significant system resources.
Other technical advantages are readily apparent to one of skill in the art from the attached figures, description, and claims.